Skip to content

TASK: Followup #5371 remove legacy CopyNodesRecursively command#5453

Merged
mhsdesign merged 3 commits intoneos:9.0from
mhsdesign:task/fully-remove-legacy-CopyNodesRecursively
Feb 20, 2025
Merged

TASK: Followup #5371 remove legacy CopyNodesRecursively command#5453
mhsdesign merged 3 commits intoneos:9.0from
mhsdesign:task/fully-remove-legacy-CopyNodesRecursively

Conversation

@mhsdesign
Copy link
Copy Markdown
Member

@mhsdesign mhsdesign commented Jan 29, 2025

And ignore events when publishing legacy copy nodes -> which could lead to lost content and conflicts in this hierarchy. Please use Neos 9 Beta 18 and before to have the changes published to the base workspace.

Since Neos 9 Beta 16 we advised, to have the legacy nod copy's published to the live workspace.
Also we provide tooling to detect those cases via:

./flow migrateevents:copynodesstatus

Followup to #5371

Upgrade instructions

Review instructions

Checklist

  • Code follows the PSR-2 coding style
  • Tests have been created, run and adjusted as needed
  • The PR is created against the lowest maintained branch
  • Reviewer - PR Title is brief but complete and starts with FEATURE|TASK|BUGFIX
  • Reviewer - The first section explains the change briefly for change-logs
  • Reviewer - Breaking Changes are marked with !!! and have upgrade-instructions

* This layer can be removed if there are no legacy events expected during rebasing
* @return iterable<EventEnvelope>
*/
private function triggerConflictForLegacyEvents(EventStreamInterface $eventStream, bool $dropLegacyEvents): iterable
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this might not be soo clever after all because this enforced to use of force and later in the code during the forced rebase other changes which were not communicated might also be dropped.

So maybe its just best to silently ignore any CopyNodesRecursively and basically auto drop them for publish, discard and rebase?

We have said for 3 betas that this will happen ...

@kitsunet
Copy link
Copy Markdown
Member

Yep, fine by me

While causing a conflict and letting it be solved via force is clever, it might have more negative user side effects:

Because of the force flag, any actual conflicts for later changes will be dropped and the user wouldnt know about them because there was just one conflict communicated.

Instead of solving this more delicate by merging this conflict with the other possible conflicts we decide to just ignore the CopyNodesRecursively as this was communicated for 3 betas.
@kitsunet kitsunet force-pushed the task/fully-remove-legacy-CopyNodesRecursively branch from 1e57565 to 2216a2c Compare February 20, 2025 14:34
@kitsunet kitsunet enabled auto-merge February 20, 2025 14:34
@kitsunet kitsunet disabled auto-merge February 20, 2025 14:55
@mhsdesign
Copy link
Copy Markdown
Member Author

@nezaniel said is fine :D

@mhsdesign mhsdesign merged commit f1c3fae into neos:9.0 Feb 20, 2025
@mhsdesign mhsdesign deleted the task/fully-remove-legacy-CopyNodesRecursively branch February 20, 2025 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

No open projects
Archived in project

Development

Successfully merging this pull request may close these issues.

2 participants